Applications sometimes need to establish and manage a session between computing devices. A session is a set of interactions between computing devices that occurs over a period of time. As an example, real-time communications applications such as MICROSOFT MESSENGER or Voice over Internet Protocol (“VoIP”) establish sessions between communicating devices on behalf of users. These applications may use various mechanisms to establish sessions, such as a “Session Initiation Protocol” (“SIP”). SIP is an application-layer control protocol that devices can use to discover one another and to establish, modify, and terminate sessions between devices. SIP is an Internet proposed standard. Its specification, “RFC 3261,” is available at the URL formed by concatenating “http://,” “www,” “.ietf,” “.org,” “/rfc,” and “/rfc3261.txt.” A specification for extensions to SIP relating to event notifications, “REC 3265,” is available at the URL formed by concatenating “http://,” “www,” “.ietf,” “.org,” “/rfc,” and “/rfc3265.txt.” A specification for locating SIP servers, “RFC 3263,” is available at the URL formed by concatenating “http://,” “www,” “.ietf,” “.org,” “/rfc,” and “/rfc32613txt.” A specification for descriptions of sessions, “RFC 2327,” is available at the URL formed by concatenating “http://,” “www,” “.ietf,” “.org,” “/rfc,” and “/rfc2327.txt.” All these specifications are incorporated herein in their entirety by reference.
Applications may use SIP with another protocol to send or receive information. As an example, an application may use SIP with Real-time Transport Protocol (“RTP”) for transporting real-time data during a session. By using SIP with other protocols, applications can create and manage a session and exchange information during the session. The protocol used with SIP to exchange information may segment the information into messages. As an example, a VoIP application may segment a long narration into shorter messages. Exchanging messages during a session is referred to as a “dialog.” SIP may use lower-level communications layers to transport a dialog's messages, such as Transmission Control Protocol/Internet Protocol (“TCP/IP”), which are commonly employed transport- and network-layer protocols.
A SIP network comprises entities that can participate in a dialog as a client, server, or both. SIP supports four types of entities: user agent, proxy server, redirect server, and registrar. User agents initiate and terminate sessions by exchanging messages with other SIP entities. A user agent can be a user agent client, which is generally a device that initiates SIP requests (e.g., to initiate a session), or a user agent server, which is a device that generally receives SIP requests and responds to such requests. As examples, “IP-telephones,” personal digital assistants, and any other type of computing device may be user agents. A device can be a user agent client in one dialog and a user agent server in another, or may change roles during the dialog. A proxy server is an entity that acts as a server to clients and a client to servers. In so doing, proxy servers intercept, interpret, or forward messages between clients and servers. Proxy servers contribute to network security by, e.g., validating senders and recipients of messages. A redirect server accepts a SIP request and generates a SIP response directing the client that sent the request to contact an alternate network resource. As an example, a redirect server may indicate at which of several devices a particular user is presently available. A registrar is a server that accepts registration information from SIP clients and informs a location service or other entities of the received registration information.
SIP supports two message types: requests, which are sent from a client to a server, and responses, which are sent from a server to a client, generally when responding to a request. A SIP message comprises three parts. The first part of a SIP message is a “start line,” which includes fields indicating a message type and a protocol version. The second part of a SIP message comprises header fields whose values are represented as name-value pairs. The third part of a SIP message is the message's body, which is used to describe the session to be initiated or contain data relating to the session. Message bodies may appear in requests or responses.
SIP messages are routed based on the contents of their header fields. To be valid, a SIP request should contain at least the following five header fields: To, From, Contact, Max-Forwards, and Via. The To header field indicates the logical identity of the recipient of the request. The From header field indicates the logical identity of the initiator of the request. The Contact header field indicates the identity of where the sender wants to receive subsequent messages of the dialog. The Max-Forwards header field indicates the number of hops a request can make before arriving at its destination. As an example, if a message from device A transits device B before arriving at destination device C, the message is said to have made two hops (e.g., devices B and C). The Via header field indicates the path taken by the request so far (e.g., a sequence of network addresses of devices through which the request has transited) and indicates the path that should be followed when routing the response. A header may also contain Record-Route fields that are used to indicate that future requests and responses should be routed through an indicated device. Network devices may insert Record-Route header fields specifying devices when forwarding a SIP message in an attempt to force subsequent messages in a dialog to be routed through the specified devices. The Record-Route header field may contain an identifier (e.g., network address) for the device and parameters. These and other header fields are described in the SIP specifications referenced above.
SIP has a notion of a dialog or session that represents a relationship between two peers that persists for some time and facilitates sequencing and routing of messages between them. To maintain a proper SIP dialog, peers need to store a SIP routing path between themselves that may include one hop but can be much larger when multiple SIP proxies (e.g., routers) separate peers.
A SIP session can be described using the Session Description Protocol (“SDP”), RFC 2327. SDP can be used to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of session initiation. SDP data describe the session name and purpose, the time the session is active, the media of the session, and the information to receive the media (e.g., addresses and ports). SDP is extensible in that new attribute-value pairs can be defined to describe custom information about a session.
A difficulty with typical real-time sessions such as instant messaging is that very few if any restrictions can be placed on who participates in a session or what can be done with the messages of the session. For example, if user A invites user B to participate in a session and user B agrees, then user B is free to invite other users to participate in the session, such as user C. User A, however, may not want user C to participate. As another example, user A may want to keep the session with user B private in the sense that no other users will be able to see the messages of that session. Even though user B may be unable to invite user C to participate in the session, user B can still effectively forward messages to user C by using a traditional copy and paste to copy the content of the message and paste it into a message of another session with user C or into an electronic mail message that is sent to user C. It would be desirable to have a technique that would allow users to place restrictions on sessions so that unwanted users cannot participate in those sessions or see the content of the messages of those sessions.